The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field.
Two major criteria for evaluating software performance are speed and memory usage. Object Oriented Programs (OOPs) such as Java are often evaluated according to these criteria. Measuring speed is relatively easy and straight forward. A software test engineer need only ran a program, and then check the times at which outputs and/or intermediate results are generated. If an intermediate step takes too long to generate a result, then the code that has run up to the intermediate point is evaluated to determine where a bottleneck or other performance restrictor lies.
Measuring the amount of memory used, however, can be much more difficult. State-of-art profilers can at best determine what software objects are consuming the most memory and which methods allocated these objects. Having only this information available is not particularly useful in diagnosing memory performance problems for several reasons. First, knowing which objects are consuming memory often does not help because multiple components in the system allocate similar types of objects. For example, string objects are often major offenders in memory consumption. However, many components in a large software system allocate strings, thus identification of an offending component is difficult. Second, knowing which methods allocated the offending objects often does not help either, since objects can be passed around, making the true source of the problem being other than the creator of the offending object. This is especially true in modern frameworks that utilize factory allocation patterns. Third, tracking allocation of objects imposes a heavy penalty on the runtime performance of the application, making profiling of a large software system impractical.